FIG. 1A depicts a schematic diagram of a portion of telecommunications system 100 that is typical in the prior art. Telecommunications system 100 comprises: a source of traffic demand forecasts 105, a source of route characteristics (or corresponding supplier facility characteristics) 106, route table generators 107-1 through 107-M, and route servers 109-1 through 109-N, wherein M and N are positive integers. FIG. 1A additionally depicts: call origin 101, incoming route 103, outgoing routes 121, 122, and 123, and call destination 113, which are interconnected within telecommunications system 100 as shown.
Call origin 101, which is well known in the art, represents a point where a call is initiated such as a telephone, a mobile station, a computer, etc., without limitation.
Incoming route 103, which is well known in the art, comprises one or more telecommunications facilities that collectively are capable of carrying a call (whether a voice call, a text message, or a data session) from call origin 101 to route servers 109, e.g., trunks, switches, networks, sub-networks, the U.S. public switched telephone network, a national telecommunications network, the Internet, etc. Incoming route 103 can be circuit-switched, packet-switched, or a combination thereof, without limitation.
Traffic demand forecasts 105, which are well known in the art, are stored in one or more data structures, and comprise predicted telecommunications traffic data for one or more periods of time, for one or more call destinations. Traffic demand forecasts are calculated based on prediction algorithms, for each hour. For example and without limitation, traffic demand forecasts 105 comprise, per call destination in a given period of time, the number of predicted calls. Traffic demand forecasts 105 may be stored in a component of route table generator 107 or in a stand-alone component, or may be supplied by an outside system, or a combination thereof, etc., without limitation.
Route characteristics 106, which are well known in the art, are stored in one or more data structures, and comprise information about any facilities and outgoing routes emanating from route server 109. For example and without limitation, route characteristics 106 comprise the call capacity of each available outgoing route and/or outgoing facility (i.e., “call-termination device”) emanating from route server 109 typically measured in calling minutes available per hour; historical information about the routes/facilities, such as maintenance periods when a facility or route might be completely unavailable; and other historical performance data such as failure rates that measure the reliability of the route/facility. Route characteristics 106 may be stored in a component of route table generator 107 or in a stand-alone component, or may be supplied by an outside system, or a combination thereof, etc., without limitation.
Route table generator 107-m, which is well known in the art, is based on a processor or data-processing system or other computing platform; m has a value between 1 and M, inclusive. Route table generator 107-m receives traffic demand forecasts 105 and route characteristics 106 and, based on these and other data, generates one or more route tables for the use of route server 109.
Route server 109-n, which is well known in the art, is based on a processor, data-processing system, computing platform, call-processing system, or call-switching platform; n has a value between 1 and N, inclusive. Route server 109-n may be co-resident with route table generator 107-m or may be a separate component from route table generator 107-m. Route server 109-n receives calls via one or more incoming routes such as incoming route 103 and, based on the contents of the route table generated by route-table generator 107-m, selects a proper outgoing facility and/or outgoing route for each call.
For purposes of clarity, only route table generator 107-1 and route server 109-1 are depicted as being connected to other elements in the figure. According to the present figure, route server 109-1 is connected to incoming route 103, route table generator 107-1, and three possible outgoing routes—routes 121, 122, and 123. As those who are skilled in the art will appreciate, however, each of the other route table generators and route servers is connected to elements equivalent to those to which route table generator 107-1 and route server 109-1 are connected. As an example, route server 109-2 might be connected to incoming route 103, a different route table generator (e.g., generator 107-3, etc.), and one or more different outgoing routes than those depicted.
Routes 121, 122, and 123, which are well known in the art, each comprises one or more telecommunications facilities capable of carrying a call (whether a voice call, a text message, or a data session) from route server 109-n to one or more call destinations (e.g., destinations 113 and 114, etc.) within one or more geographic regions, or to an intermediate destination, e.g., trunks, switches, networks, sub-networks, the U.S. public switched telephone network, a national telecommunications network, the Internet, etc. Outgoing routes 121, 122, and 123 each can be circuit-switched, packet-switched, or a combination thereof, without limitation.
Call destinations 113 and 114, which are well known in the art, each represents a termination point where a call can be answered, such as a telephone, a mobile station, a computer, a switch, an answering machine, an incoming voice-response system, etc., without limitation. A call destination can be represented by any suitable addressing scheme such as a dialed number, a “Dialed Number Identification Service” (“DNIS”), a “Uniform Resource Locator” (“URL”), or a data endpoint address, a country code, or a city code, or an area code, or a combination thereof, etc., without limitation. Call destination identification is well known in the art. Call destinations 113 and 114 can be situated in the same geographic region or in different geographic regions E.
FIG. 1B depicts a more detailed schematic diagram of a portion of prior-art telecommunications system 100 depicted in FIG. 1A, including call 1B being routed to and answered at call destination 114. In addition to the components and elements described in FIG. 1A, FIG. 1B additionally depicts: call 1B originating at call origin 101, a call attempt at the ingress to route server 109-1, a call seizure at the egress from route server 109-1 via outgoing route 123, and an answered call at call destination 114.
In processing call 1B, route table generator 107-1 generates a route table, which comprises route 123 for call destination 114 for the applicable time period. Route table generator 107-1 transmits the route table to route server 109-1. Route server 109-1 receives the route table and establishes it as the operative route table to be used during the applicable time period.
As shown here, call 1B comes into route server 109-1 as a call attempt. Route server 109-1 receives call 1B and applies the route table, which is the operative route table to be used during the present time period. According to the route table, route 123 is the only allowed route to be used during the present time period. Accordingly, route server 109-1 places call 1B onto the telecommunications facilities (i.e., one or more call-termination devices) corresponding to route 123, sending call 1B onwards towards call destination 114—this operation represents a call seizure.
As shown here, call 1B successfully reaches call destination 114, where the call is answered. Accordingly, call 1B is an answered call.
As discussed above, the traffic demand forecasts of various call destinations and the call capacities of call-termination devices are used for generating route tables and, as a result, for routing calls to the call destinations. In addition to the traffic demand forecasts and call capacities, various other input parameters are also considered in generating the route tables, such as the availabilities of call-termination devices, the historical performances of the call-termination devices, and any constraints imposed by technicians or other users. Traditionally, these input parameters have often been taken into account by using some degree of manual intervention on the part of the user.
There are several problems that can occur by using such manual intervention. First, the traffic demands of the various call destinations are, at times, difficult to predict and can change significantly from one time period to the next. For example, although it is common knowledge that call traffic occurring on a holiday such as Mother's Day is much higher than on other days, it is uncertain exactly how the added traffic will affect the individual call destinations. This results in blocked calls. Second, there is a significant amount of waste that occurs as a result of manually partitioning the call capacity allocated across geographic regions and across call destinations, within a given call-termination device. This is because a capacity partitioning that might be optimal for a first hourly period might be sub-optimal for the next hourly period. And third, although the capacity allocation is administered for each call-termination device, it is difficult to monitor the loads and capacities of the individual devices.
Therefore, what is needed is a capacity allocation system that avoids at least some of the disadvantages in the prior art.